As computers have been developed to perform a greater number of instructions at greater speeds, many types of architectures have been developed to optimize this process. For example, a reduced instruction set computer (RISC) device utilizes fewer instructions and greater parallelism in executing those instructions to ensure that computational results will be available more quickly than the results provided by more traditional data processing systems. In addition to providing increasingly parallel execution of instructions, some data processing systems implement out-of-order instruction execution to increase processor performance. Out-of-order instruction execution increases processor performance by dynamically allowing instructions dispatched with no data dependencies to execute before previous instructions in an instruction stream that have unresolved data dependencies. In some data processing systems, instructions are renamed and instruction sequencing tables, also referred to as re-order buffers, facilitate out-of-order execution by re-ordering instruction execution at instruction completion time.
Re-order buffer devices are also used to allow speculative instruction execution. Therefore, data processing systems which support speculative instruction execution can be adapted for out-of-order execution with the addition of relatively minimal hardware. A portion of this added hardware includes issue logic which is used to determine a time and order that instructions should be issued. Such issue logic can be extremely complex since the dependencies of instructions and a state of a pipeline in which the instructions are being executed must be examined to determine a time at which the instruction should issue. If the issue logic is not properly designed, such issue logic can become a critical path for the data processing system and limit the frequency of instruction execution such that performance gains which could be achieved by out-of-order issue are destroyed.
The out-of-order instruction execution implemented by many prior art systems increases processor performance by dynamically allowing instructions dispatched with no data dependencies to execute before previous instructions in the instruction stream that have unresolved data dependencies. Register file renaming, renaming selected bits of architected facilities such as floating point status and control registers (FPSCR), and instruction sequencing tables (re-order buffers) facilitate out-of-order execution by re-ordering instruction execution at instruction completion time. For more information on such structures, refer to "An Efficient Algorithm for Exploiting Multiple Arithmetic Units," by R. M. Tomasulo, published in IBM Journal, January 1967, pp. 25-33. It should be noted that these devices are also used to allow speculative instruction execution. Therefore, system architecture supporting speculative instruction execution can be adapted for out-of-order execution with the addition of relatively "little" hardware and few overhead expenses. Thus, register file renaming may support out-of-order execution without modification from a speculative instruction execution architecture. However, in order to support out-of-order execution of floating point instructions, additional mechanisms have been required. Because the floating point status and control register (FPSCR) associated with the execution of floating point instructions contains a history of prior executing instructions, renaming the FPSCR is inadequate to support out-of-order instruction execution. When an instruction executes out-of-order, results from earlier instructions in an instruction stream are unavailable as partial results are sometimes saved in the rename buffer.
Therefore, mechanisms have been introduced that maintain a history of instruction execution exceptions for each instruction which is finished out-of-order. This allows the architected register to be reproduced and completed as if the instruction had executed in instruction sequence. The exception history from instructions that have previously completed, or are completing in a current cycle are also reordered. In this way, an FPSCR status for sticky exception bits of the FPSCR may be determined. With respect to non-sticky status for the FPSCR, the status is derived from a last instruction completing in a given cycle that modifies this status. Status information is also reported to a re-order buffer which allows interrupts to be posted as if the instructions were executed in an instruction order.
However, this mechanism for out-of-order floating point instruction execution does not allow for the out-of-order execution of a class of floating point instructions. These are instructions that operate on the FPSCR directly, or are register-to-register instructions that alter the condition register, that is, have a recording bit set. These will collectively be called FPSCR instructions. Such instructions, which source the status bits of the FPSCR, must execute "in order" to read the correct status from all prior, with respect to program order, floating point instructions.
To accomplish the sourcing of a correct FPSCR, the execution of FPSCR instructions have been serialized, wherein FPSCR instructions are not issued until all prior, in program order, FPU rr instructions have completed. Such serialization is slow. FPSCR instructions may appear frequently in floating point operations, particularly in an object oriented prograrmning paradigm. Floating point subroutines, usually referred to as methods in the object oriented programming art, must ensure the rounding mode of the operation. Functions are defined to operate in specific floating point rounding modes independently of the rounding mode in the program code calling the function. In order to perform the required rounding mode transactions, multiple FPSCR instructions are executed. Therefore, to improve performance in execution of object oriented software, there is a need in the art for a mechanism to execute FPSCR instructions without serialization, and which is compatible with existing out-of-order floating point execution mechanisms.